Celestin Apprentice 5/Apprentice-Release5.iso/Information/THINK C Digest/1991/91-06

Text File | 1995-12-31 | 62KB | 1,795 lines

Path: ucivax!gateway
From: [e-mail] (Tsuyoshi Motegi)
Subject: 4plus-14 + Think-c-4.0.5
Message-ID: <[e-mail]>
Newsgroups: fa.think-c
Lines: 12
Date: 3 Jun 91 13:26:25 GMT

I tried to use 4plus 1.4 with Think-C 4.0.5 on System7, but no extra
menu specific to 4plus appeared in the menu bar.  I put 4plus into the
extension in the system folder and 4plus startup icon popped at
startup.  I have never used 4plus before, so I missed something
important.  Please advise if you have any idea.

Thanks,

=-=-=-=-=-=-=--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Tsuyoshi Motegi            [e-mail]
Dept. of Computer Science    Stanford University
=-=-=-=-=-=-=--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=










Path: ucivax!gateway
From: [e-mail] ("Russell S. Finn")
Subject: Re: 4plus-14 + Think-c-4.0.5
Message-ID: <[e-mail]>
In-Reply-To: Tsuyoshi Motegi's message of 03 Jun 91 13:26:25 +0000.
             <[e-mail]>
Newsgroups: fa.think-c
Lines: 6
Date: 4 Jun 91 01:26:47 GMT

Because of the way 4Plus works, you'll have to place it directly in
the System Folder (*not* in the Extensions folder) for it to work.
Once you do this, it works fine under System 7.

-- Russell S. Finn
[e-mail]










Path: ucivax!gateway
From: [e-mail] (Tsuyoshi Motegi)
Subject: 4plus-14 + Think-c-4.0.5 (Summary)
Message-ID: <[e-mail]>
Newsgroups: fa.think-c
Lines: 5
Date: 4 Jun 91 01:58:47 GMT

I thank those who replied so soon to fix the problem.  4plus 1.4 works
fine with Think C 4.0.5 on System7 when I moved it from the extension
folder to the top level of the system folder.

                        --tm










Path: ucivax!gateway
From: [e-mail] (opcode ranger)
Subject: Problems getting "profile" to work under System 7
Message-ID: <[e-mail]>
Newsgroups: fa.think-c
Lines: 12
Date: 4 Jun 91 22:51:36 GMT
X-Vmsmail-To: @THINKC

I was trying to do some profiling with THINK C 4.0.5 under Sys 7 today.  I
installed the proper libraries I belive (profile, ANSI) and did InitProfile()
and DumpProfile(), but during writing out the profile information, it kept
crashing with the TMON error message: "Writing supervisor byte at xxxxx" (or
something like that, with xxxxx being an address).

Anybody have any idea what's going on?  I got the THINK 4.0.5 updater, but I
noticed no new ANSI or profile libs.  I'm running w/o VM or 32 bit on a Mac II
(w/PMMU).  I'd really like to get the profiling going (our client wants the
code speeded up), so any help much appreciated!

Robert










Path: ucivax!gateway
From: infoserv!apple!well![e-mail] (John Draper)
Subject: GWorld question...
Message-ID: <[e-mail]>
Newsgroups: fa.think-c
Lines: 80
Date: 5 Jun 91 18:59:28 GMT


 A GWorld question.....

 I am trying to use the new 32bit QuickDraw calls relating to
GWorlds.   I want to be able to change the size of an existing
GWorld.    I am using the "UpdateGWorld" call which I have source
code for the glue code which I will partially include here.

pascal GWorldFlags UpdateGWorld( offscreenGWorld, pixelDepth, boundsRect,
cTable, aGDevice, flags )
    GWorldPtr        *offscreenGWorld;
    short            pixelDepth;
    Rect            *boundsRect;
    CTabHandle        cTable;
    GDHandle        aGDevice;
    GWorldFlags        flags;
{
    asm {
        SUBQ        #4,SP
        MOVE.L        offscreenGWorld(A6),-(SP)
        MOVE.W        pixelDepth(A6),-(SP)
        MOVE.L        boundsRect(A6),-(SP)
        MOVE.L        cTable(A6),-(SP)
        MOVE.L        aGDevice(A6),-(SP)
        MOVE.L        flags(A6),-(SP)
        MOVEQ        #3,D0
        DC.W        0xAB1D
        MOVE.L        (SP)+,D0
    }
}

    I use the standard C Code in a method to an object listed below.
I make sure the objects handle is locked on the heap because I am
referencing a POINTER to "macGWorld" which is an instance variable.
and don't want the rug from getting pulled out under my feet.

    Rect    *r;        /* Is the NEW rect I want to use, and is passed
                        into this method as an argument */

    saveHState = HGetState( this );
    MoveHHi( this );    HLock( this );

    res = UpdateGWorld(    &macGWorld,
                    (**(this->macGWorld->portPixMap)).pixelSize,
                    r,
                    0, 0,
                    (GWorldFlags)0 );

    HSetState( this, saveHState);

    Note that I am passing a NIL as a cTable handle.  The "Preliminary
Developer note" released by Apple dated 11/1/90 says that the "CTable
have the same meaning and work *generally* in the same way as in
NewGWorld call.   The manual then says "if cTable is NIL,  the default
color table for that pixelDepth will be used".   This is exactly what
I want.    However,  the Jasik Debugger squawks at the UpdateGWorld
function call however "res" still returns NIL.    In particular,  it
happens when UpdateGWorld calls a DisposHandle with a NIL pointer
somewhere in 32bitQD land.   I am using 32bit QD ver 1.1, System 6.0.4,
8 mb ram in Mac II.

    Is Apple 32bit QD code not testing the "NIL",  or am I supposed to
be passing in a REAL color table?   I do NOT want to use any Memory Manager
calls to allocate anything,   and was hoping the UpdateGWorld would
change the size as specified by "r" above and leave it's existing color
table alone,  and thus not make any MM (Memory Manager) calls.

    Is there another legal way I can change an existing Mac GWorld to
a new bounds?   Setting the new PixMap bounds will NOT work,  because
the BaseAddress allocations (Which are being done in Temp memory), will
have to be re-allocated with new size.   There are a lot of other
allocations which have to be changed,  but the GWorld concept is supposed
to shield us from all this insanity.

    Anyway,  there most be SOMEONE out there in Net land who might know
what is REALLY going on.

Thanx in advance...

John D.










Path: ucivax!gateway
From: [e-mail] ("Matthew T. Russotto")
Subject: Re:  GWorld question...
Message-ID: <[e-mail]>
Newsgroups: fa.think-c
Lines: 2
Date: 5 Jun 91 20:36:01 GMT

Do you expect the GWorld to be returned in 'res'?  It won't-- you will get
flags there, and '0' means 'no error'.










Path: ucivax!gateway
From: [e-mail] ("G.Anderson - Computing Services")
Subject: Re:  Think C Class Libraries
Message-ID: <[e-mail]>
Newsgroups: fa.think-c
Lines: 2
Date: 6 Jun 91 17:58:47 GMT


oking for??










Path: ucivax!gateway
From: [e-mail]
Subject: Think C parser problems
Message-ID: <[e-mail]>
Newsgroups: fa.think-c
Lines: 32
Date: 6 Jun 91 22:48:12 GMT

I've just found something wrong with the Think C 4.02 parser.
The following code drove me nuts for awhile because of a typo
(the != (not equal operator) was typed as =!),
the code compiled fine and when Data was '5' (char), after
stepping through the "while" line, Data changed to '\0' (char) and
the while failed.
My guess is that there is something wrong with the Think C parser
or with my version of it. Any comments !


 do {
  ...
        } while (Data =! '\n');


Also last week while compiling OIC ( Objects-in-C ,V1.02)
I Had to change "some" of the K&R style function declarations to
ANSI, because the compiler complained with the following message
"invalid function definition". Any comments !!

/*method list
get_supers(list, class)
    list    list;
    class    class;
*/
method list get_supers(list    list, class    class)


Carlos Bazzarella.
University of Waterloo.
[e-mail]











Path: ucivax!gateway
From: [e-mail]
Subject: (none)
Message-ID: <[e-mail]>
Newsgroups: fa.think-c
Lines: 8
Date: 6 Jun 91 23:04:44 GMT

I've just realized what happened for the first case:

Data =! '\n'

was interpreted as to take the logical not of 13 (decimal) which
is Zero and assign to Data. Nothing wrong with the parser, but
still weird at first.











Path: ucivax!gateway
From: [e-mail] (Pete Resnick)
Subject: Re: Think C parser problems
Message-ID: <[e-mail]>
Newsgroups: fa.think-c
Lines: 26
Date: 6 Jun 91 23:33:16 GMT

[e-mail] writes:

>the code compiled fine and when Data was '5' (char), after
>stepping through the "while" line, Data changed to '\0' (char) and
>the while failed.
>My guess is that there is something wrong with the Think C parser
>or with my version of it. Any comments !
>
>
> do {
>  ...
>        } while (Data =! '\n');

That worked just the way it should have. The statement "Data = !'\n'"
parses just fine. You set Data equal to the logical-not of '\n', which is
unsuprisingly 0. This is exactly what it should have done.

pr

--
Pete Resnick        (...so what is a mojo, and why would one be rising?)
Graduate assistant - Philosophy Department, Gregory Hall, UIUC
System manager - Cognitive Science Group, Beckman Institute, UIUC
Internet/ARPAnet/EDUnet  : [e-mail]
BITNET (if no other way) : FREE0285@UIUCVMD











Path: ucivax!gateway
From: [e-mail] (Freitag and Pertinax)
Subject: Re:  Think C parser problems
Message-ID: <[e-mail]>
Newsgroups: fa.think-c
Lines: 14
Date: 7 Jun 91 03:11:09 GMT

> do {
>  ...
>        } while (Data =! '\n');

This is perfectly legal C syntax, though clearly not what you intended.
There's nothing wrong with the parser.  (Or, at least, there is no reason
for it in this case to complain.)

It's simply an assignment of Data to !'\n'.  I'm surprised that you
got variant results going through the looping depending on the prior
value of Data, though.  I should think it would always assign Data = 0.

Paul DuBois
[e-mail]










Path: ucivax!gateway
From: [e-mail] (John Labovitz)
Subject: interesting "bug" in Think C
Message-ID: <[e-mail]>
X-Mailer: ELM [version 2.3 PL3]
Newsgroups: fa.think-c
Lines: 26
Date: 7 Jun 91 11:45:13 GMT

I always wondered why getting into the font/tab dialog box
took so damn long with more than a dozen or so fonts loaded.
I think I know why now.

Usually I program in some interesting font like Garamond
or Palatino, but today I wanted to use Helvetica.  I opened
up the font/tab dialog box, selected Helvetica from the font
pop-up menu, then clicked on the size pop-up menu.  Rather
than the expected 9, 10, 12, 14, 18, 24 sizes, I instead got
this wonderfully huge menu that listed sizes from 9 to 127!

I assume this is because I'm now running System 7, which has
TrueType, and Think C is doing something like:

    for (size = 9; size < 127; size++)
        if (RealFont(fontNum, size))
            /* insert the size in the menu */

and the Font Manager replies with TRUE on them all.

This doesn't happen with non-TrueType fonts.

--
John Labovitz        Domain: [e-mail]        Phone: [phone]
Barn Communications    UUCP:   ..!hoptoad!barn!jsl











Path: ucivax!gateway
From: [e-mail] (John J Chew)
Subject: Re:  interesting "bug" in Think C
Message-ID: <[e-mail]>
Newsgroups: fa.think-c
Lines: 26
Date: 7 Jun 91 13:48:37 GMT

In reply to the following from John Labovitz <[e-mail]>:
> I assume this is because I'm now running System 7, which has
> TrueType, and Think C is doing something like:
>
>     for (size = 9; size < 127; size++)
>         if (RealFont(fontNum, size))
>             /* insert the size in the menu */
>
> and the Font Manager replies with TRUE on them all.
>
> This doesn't happen with non-TrueType fonts.

... which is something that has always bothered me.  I would like to be able
to use generated sizes of ATM fonts, but they of course return false from
RealFont().  [ And yes I know I can ResEdit the size by hand .... ]

It would be nice to be able to choose a font from a popup-with-editable-
text-field as suggested in HIN #9.

John
--
John J. Chew, III
AIS/Berger-Levrault * phone [phone]  * [e-mail]
18, rue des Glacis  * fax   [phone]  * [e-mail]
F-54017 Nancy Cedex * telex BL NANCY 960 212 * [e-mail]
"Ca ne se fait pas ici."










Path: ucivax!gateway
From: [e-mail] (Francois Menneteau)
Subject: Re: Think C parser problems
Message-ID: <[e-mail]>
In-Reply-To: [e-mail]
       "Think C parser problems" (Jun  6, 22:48)
Newsgroups: fa.think-c
Lines: 26
Date: 7 Jun 91 14:20:19 GMT
X-Organization: IMAG Institute, University of Grenoble

Dans votre courrier du 6 Jun vous ecrivez :
>I've just found something wrong with the Think C 4.02 parser.
>The following code drove me nuts for awhile because of a typo
>(the != (not equal operator) was typed as =!),
>the code compiled fine and when Data was '5' (char), after
>stepping through the "while" line, Data changed to '\0' (char) and
>the while failed.
>My guess is that there is something wrong with the Think C parser
>or with my version of it. Any comments !
>
>
> do {
>  ...
>        } while (Data =! '\n');
>

In C this line is interpreted as Data = neg('\n') ; where neg() is the
negative value of the parameter.
However !'\n' is not equal to '\0' (I think it would be 3). Are you sure
of the value ?

--
Francois Menneteau ()   __|||||__   () "... I had their lives in my hands
================== ()    /O   O\    () their fate their fortune in my visions
[e-mail]       ()    - .|. -    () No one believed in my true prophecy
================== ()     \=^=/     () And now it's too late."  (Iron Maiden)










Path: ucivax!gateway
From: infoserv!apple!well![e-mail] (John Draper)
Subject: GWorld question - 2nd try at posting it.
Message-ID: <[e-mail]>
Newsgroups: fa.think-c
Lines: 80
Date: 8 Jun 91 18:06:14 GMT


 A GWorld question.....

 I am trying to use the new 32bit QuickDraw calls relating to
GWorlds.   I want to be able to change the size of an existing
GWorld.    I am using the "UpdateGWorld" call which I have source
code for the glue code which I will partially include here.

pascal GWorldFlags UpdateGWorld( offscreenGWorld, pixelDepth, boundsRect,
cTable, aGDevice, flags )
    GWorldPtr        *offscreenGWorld;
    short            pixelDepth;
    Rect            *boundsRect;
    CTabHandle        cTable;
    GDHandle        aGDevice;
    GWorldFlags        flags;
{
    asm {
        SUBQ        #4,SP
        MOVE.L        offscreenGWorld(A6),-(SP)
        MOVE.W        pixelDepth(A6),-(SP)
        MOVE.L        boundsRect(A6),-(SP)
        MOVE.L        cTable(A6),-(SP)
        MOVE.L        aGDevice(A6),-(SP)
        MOVE.L        flags(A6),-(SP)
        MOVEQ        #3,D0
        DC.W        0xAB1D
        MOVE.L        (SP)+,D0
    }
}

    I use the standard C Code in a method to an object listed below.
I make sure the objects handle is locked on the heap because I am
referencing a POINTER to "macGWorld" which is an instance variable.
and don't want the rug from getting pulled out under my feet.

    Rect    *r;        /* Is the NEW rect I want to use, and is passed
                        into this method as an argument/

    saveHState = HGetState( this );
    MoveHHi( this );    HLock( this );

    res = UpdateGWorld(    &macGWorld,
                    (**(this->macGWorld->portPixMap)).pixel,
                    r,
                    0, 0,
                    (GWorldFlags)0 );

    HSetState( this, saveHState);

    Note that I am passing a NIL as a cTable handle.  The "Preliminary
Developer note" released by Apple dated 11/1/90 says that the "CTable
have the same meaning and work *generally* in the same way as in
NewGWorld call.   The manual then says "if cTable is NIL,  the default
color table for that pixelDepth will be used".   This is exactly what
I want.    However,  the Jasik Debugger squawks at the UpdateGWorld
function call however "res" still returns NIL.    In particular,  it
happens when UpdateGWorld calls a DisposHandle with a NIL pointer
somewhere in 32bitQD land.   I am using 32bit QD ver 1.1, System 6.0.4,
8 mb ram in Mac II.

    Is Apple 32bit QD code not testing the "NIL",  or am I supposed to
be passing in a REAL color table?   I do NOT want to use any Memory Manager
calls to allocate anything,   and was hoping the UpdateGWorld would
change the size as specified by "r" above and leave it's existing color
table alone,  and thus not make any MM (Memory Manager) calls.

    Is there another legal way I can change an existing Mac GWorld to
a new bounds?   Setting the new PixMap bounds will NOT work,  because
the BaseAddress allocations (Which are being done in Temp memory), will
have to be re-allocated with new size.   There are a lot of other
allocations which have to be changed,  but the GWorld concept is supposed
to shield us from all this insanity.

    Anyway,  there most be SOMEONE out there in Net land who might know
what is REALLY going on.

Thanx in advance...

John D.










Path: ucivax!gateway
From: infoserv!apple!well![e-mail] ("Kenton A. Hoover")
Subject: Test
Message-ID: <[e-mail]>
Newsgroups: fa.think-c
Lines: 6
Date: 9 Jun 91 18:06:46 GMT

Test for bounce.

| Kenton A. Hoover             Chief Engineer |         [e-mail] |
| Whole Earth 'Lectronic Link [phone] | [e-mail] |
|=============================================================================|
|                   Complain all you want -- I'll ignore.                     |










Path: ucivax!gateway
From: infoserv!apple!well![e-mail] (John Draper)
Subject: 3rd try in posting...
Message-ID: <[e-mail]>
Newsgroups: fa.think-c
Lines: 82
Date: 9 Jun 91 18:06:48 GMT



 A GWorld question.....

 I am trying to use the new 32bit QuickDraw calls relating to
GWorlds.   I want to be able to change the size of an existing
GWorld.    I am using the "UpdateGWorld" call which I have source
code for the glue code which I will partially include here.

pascal GWorldFlags UpdateGWorld( offscreenGWorld, pixelDepth, boundsRect,
cTable, aGDevice, flags )
    GWorldPtr        *offscreenGWorld;
    short            pixelDepth;
    Rect            *boundsRect;
    CTabHandle        cTable;
    GDHandle        aGDevice;
    GWorldFlags        flags;
{
    asm {
        SUBQ        #4,SP
        MOVE.L        offscreenGWorld(A6),-(SP)
        MOVE.W        pixelDepth(A6),-(SP)
        MOVE.L        boundsRect(A6),-(SP)
        MOVE.L        cTable(A6),-(SP)
        MOVE.L        aGDevice(A6),-(SP)
        MOVE.L        flags(A6),-(SP)
        MOVEQ        #3,D0
        DC.W        0xAB1D
        MOVE.L        (SP)+,D0
    }
}

    I use the standard C Code in a method to an object listed below.
I make sure the objects handle is locked on the heap because I am
referencing a POINTER to "macGWorld" which is an instance variable.
and don't want the rug from getting pulled out under my feet.

    Rect    *r;        /* Is the NEW rect I want to use, and is passed
                        into this method as an argument/

    saveHState = HGetState( this );
    MoveHHi( this );    HLock( this );

    res = UpdateGWorld(    &macGWorld,
                    (**(this->macGWorld->portPixMap)).pixel,
                    r,
                    0, 0,
                    (GWorldFlags)0 );

    HSetState( this, saveHState);

    Note that I am passing a NIL as a cTable handle.  The "Preliminary
Developer note" released by Apple dated 11/1/90 says that the "CTable
have the same meaning and work *generally* in the same way as in
NewGWorld call.   The manual then says "if cTable is NIL,  the default
color table for that pixelDepth will be used".   This is exactly what
I want.    However,  the Jasik Debugger squawks at the UpdateGWorld
function call however "res" still returns NIL.    In particular,  it
happens when UpdateGWorld calls a DisposHandle with a NIL pointer
somewhere in 32bitQD land.   I am using 32bit QD ver 1.1, System 6.0.4,
8 mb ram in Mac II.

    Is Apple 32bit QD code not testing the "NIL",  or am I supposed to
be passing in a REAL color table?   I do NOT want to use any Memory Manager
calls to allocate anything,   and was hoping the UpdateGWorld would
change the size as specified by "r" above and leave it's existing color
table alone,  and thus not make any MM (Memory Manager) calls.

    Is there another legal way I can change an existing Mac GWorld to
a new bounds?   Setting the new PixMap bounds will NOT work,  because
the BaseAddress allocations (Which are being done in Temp memory), will
have to be re-allocated with new size.   There are a lot of other
allocations which have to be changed,  but the GWorld concept is supposed
to shield us from all this insanity.

    Anyway,  there most be SOMEONE out there in Net land who might know
what is REALLY going on.

Thanx in advance...

John D.











Path: ucivax!gateway
From: [e-mail] (Hans van der Meer)
Subject: think-list
Message-ID: <[e-mail]>
Newsgroups: fa.think-c
X-Telex: 16460 facwn nl
Lines: 2
Date: 10 Jun 91 07:29:05 GMT
X-Phone: [phone]
X-Fax: [phone]
X-Organisation: Faculty of Mathematics & Computer Science
                University of Amsterdam
                Plantage Muidergracht 24
                NL-1018 TV Amsterdam
                The Netherlands

please remove me from the list.
Hans van der Meer: [e-mail]










Path: ucivax!gateway
From: [e-mail]
Subject: ThinkC 4.0.5
Message-ID: <[e-mail]>
X-Mailer: ELM [version 2.2 PL0]
Newsgroups: fa.think-c
Lines: 10
Date: 10 Jun 91 14:14:24 GMT

How does someone with only UUCP access or a US mail address get the ThinkC
4.0.5 update?

I am just surprised to not have received a notice from Symantec concerning
the required upgrade for running under System 7.0.

--
    Piper Keairnes     *     [e-mail]      *
  Unisys Corporation   *  uunet!rsvl.unisys.com!piper   *
Open Software Products *      Roseville, MN 55108       *










Path: ucivax!gateway
From: [e-mail] (John Fearnside)
Subject: please remove me
Message-ID: <[e-mail]>
Newsgroups: fa.think-c
Lines: 4
Date: 10 Jun 91 14:15:53 GMT


Please remove me from the THINK C mailing list, thanks.
[e-mail]











Path: ucivax!gateway
From: [e-mail] (Phil Shapiro)
Subject: ThinkC 4.0.5
Message-ID: <[e-mail]>
In-Reply-To: [e-mail]'s message of 10 Jun 91 14:14:24 GMT <[e-mail]>
Newsgroups: fa.think-c
Lines: 20
Date: 10 Jun 91 17:10:44 GMT

   How does someone with only UUCP access or a US mail address get the
   ThinkC 4.0.5 update?

Well, you can either use a ftp mailer program, or use the Symantec BBS
[phone], or call up Tech Support at Symantec [phone].
You may also email me with your mailing address (US and otherwise).

   I am just surprised to not have received a notice from Symantec
   concerning the required upgrade for running under System 7.0.

Since the update is technically a minor update, we did not mail users
about it.  It was hoped that users would run Apple's Compatability
Checker, find out that THINK C 4.0 was incompatible with System 7, and
contact us directly.

    -phil
----
   Phil Shapiro                           Technical Support Analyst
   Language Products Group                     Symantec Corporation
        Internet: [e-mail]










Path: ucivax!gateway
From: [e-mail] (Mark Alldritt)
Subject: CDirector question
Message-ID: <9106101203*[e-mail]>
Newsgroups: fa.think-c
Lines: 19
Date: 10 Jun 91 18:22:55 GMT

Hello All,

In the TCL documentation is explicitly states that the supervisor of a CDirector
must be the application.  Is this really true?  The reason I ask is this:

I have written a series of classes the present modal and non-modal dialogs (who
has not?).  I want to create a director for a non-modal dialog that is linked to
a document.  It seems to me that the supervisor of this new director should be
the document, not the application.  This would allow for the proper bubbling
up of UpdateMenus and DoCommand method calls.

An alternative to all this is to treat the non-modal dialog as a second window
(my modal and non-modal dialogs are subclasses of CWindow) for the document,
but this does not appear to be supported either.

I hope I have not missed something obvious here.

Thanks in advance,
Mark










Path: ucivax!gateway
From: [e-mail] (Steve Leeke)
Subject: Remove
Message-ID: <[e-mail]>
Newsgroups: fa.think-c
Reply-To: [e-mail]
Lines: 4
Date: 10 Jun 91 22:06:34 GMT

Please remove me from this mailing list.

Steve Leeke
[e-mail]










Path: ucivax!gateway
From: [e-mail] (Martin Minow 10-Jun-1991 1927)
Subject: re: CDirector question
Message-ID: <[e-mail]>
Newsgroups: fa.think-c
Lines: 27
Date: 10 Jun 91 23:33:28 GMT

Mark Alldritt notes that TCL requires the supervisor of a CDirector to
be the application.  He has a dialog/window that needs to be attached to
a document (rather than a window).

When I was faced with a similar problem, I ended up adding an instance
variable to the dialog's CDirector that is the "real" supervisor and letting
DoCommand and similar toss inheritance onward.  I.e., DoCommand would be
    void
    MyDirector::DoCommand(
        long        theCommand
        )
    {
        switch (theCommand) {
        case myCmdNo:    ...
                break;
        default:    if (myRealSupervisor != NULL)
                    myRealSupervisor->DoCommand(theCommand);
                else {
                    inherited::DoCommand(theCommand);
                }
        }
    }

Look at the way CPanorama and CScrollBar work together for other ideas.

Martin.
[e-mail]










Path: ucivax!gateway
From: [e-mail] ("0000-uucp(0000")
Subject: (none)
Message-ID: <9106101633.AA06900@p4tustin>
Newsgroups: fa.think-c
Lines: 40
Date: 10 Jun 91 23:35:13 GMT

>From compaq.com!moxie!Buster.Stafford.TX.US!brain!chuck  Mon Jun 10 12:29:18 1991 remote from uunet
Received: from cs.utexas.edu by relay2.UU.NET with SMTP

    (5.61/UUNET-internet-primary) id AA06284; Mon, 10 Jun 91 12:29:18 -0400
Received: from WOTAN.COMPAQ.COM by cs.utexas.edu (5.64/1.101) with SMTP
    id AA10062; Mon, 10 Jun 91 11:29:02 -0500
Received: by compaq.com (Smail3.1.19)
    id <[e-mail]>; Mon, 10 Jun 91 11:28 CDT
Received: by moxie.hou.tx.us (Smail3.1.19)
    id <[e-mail]>; Mon, 10 Jun 91 10:41 CDT
Received: from Buster.Stafford.TX.US by Menudo.UH.EDU with UUCP id AA10169
  (5.65b+/IDA-1.4.3 for Moxie.Hou.TX.US!wotan!cs.utexas.edu!uunet!p4tustin!ucivax!think-c); Mon, 10 Jun 91 10:22:38 -0500
Received: by buster.stafford.tx.us (5.51/smail2.2/06-30-87)
    id AA01734; Mon, 10 Jun 91 10:20:15 CDT
From: uunet!cs.utexas.edu!brain!chuck (Chuck Shotton)
To: infoserv!apple!well![e-mail]
Subject: Re: Test
Date: Mon, 10 Jun 91 08:09:12 CDT
Cc: [e-mail]
Organization: BIAP Systems
Reply-To: uunet!cs.utexas.edu!brain!chuck
Message-Id: <[e-mail]>
X-Mailer: uAccess - Mac Release: 1.0.4a


In Regards to your letter <[e-mail]>:
> Test for bounce.
>
> | Kenton A. Hoover             Chief Engineer |         [e-mail] |
> | Whole Earth 'Lectronic Link [phone] | [e-mail] |
> |=============================================================================|
> |                   Complain all you want -- I'll ignore.                     |
>

Nope, it didn't bounce! :)

-----------------------------------------------------------------------
Chuck Shotton                 Internet:  [e-mail]
                              UUCP:      ...!buster!brain!chuck
"Your silly quote here."      AppleLink: D1683       MacNet: shotton










Path: ucivax!gateway
From: [e-mail] (Mark Nagel)
Subject: ADMIN: List Information [PLEASE READ]
Message-ID: <[e-mail]>
Newsgroups: fa.think-c
Reply-To: [e-mail]
Organization: University of California, Irvine - Dept of ICS
Lines: 81
Date: 11 Jun 91 01:59:43 GMT
X-Phone: [phone] x115

Time again for a gentle reminder to all about how to subscribe,
unsubscribe, and handle general administrative requests.  If you
haven't read this, please do.  If you read it but still don't know
the difference between think-c and think-c-request, please read it
again.  Many of the list subscribers would appreciate it...

Thanks,
Mark

        About... The Think C electronic mailing list
        --------------------------------------------

This list has been created to discuss topics of interest among users of
Symantec's Think C compiler for the Macintosh personal computer.  These
topics include:

    o programming tips and examples

    o discussion of compiler bugs and/or misfeatures and workarounds

    o questions related to programming the Macintosh with Think C and/or
      object-oriented programming

One request: if someone submits a question on something that seems simple to
you, please remember that it will seem simple to many of the other 350+
subscribers to the list.  Please reply to the sender directly unless you
feel it is warranted to broadcast the reply.  The person who submitted the
question is urged to followup at some time in the future with a summary of
responses, so others who might be interested can see what the solution was.
This simple rule will prevent much of the chaff that is present on many
mailing lists and newsgroups.

Archives of past discussions on the list are stored in the Think C Archive
(see below for access information) in the directory /mac/think-c/archives.

***Requests*** for addition/deletion/address/questions changes should be
sent to:

    [e-mail]

***Submissions to the list*** should be sent to:

    [e-mail]

            About... The Think C Archive
            ----------------------------

An archive of submitted source code and other packages related to Think C is
available from ics.uci.edu via two transfer methods:

    o anonymous ftp to ics.uci.edu (128.195.1.1)

    o automated e-mail archive server on ics.uci.edu

The archive is stored in /mac/think-c for ftp.  To use the archive server,
send mail to:

    [e-mail]

Extensive help is available for this server by using a subject consisting of
the word "help."  For there, you should be able to determine how to navigate
the archive.

Submissions to the archive may be accomplished in one of two ways:

    o use anonymous ftp to drop the submission in /incoming on
      ics.uci.edu and send a note to think-c-request summarizing the
      submission.

    o use electronic mail to send the submission to think-c-request.

After the submission has been moved to the proper directory in the archive,
a notice will be sent to the list describing the new addition(s) to the
archive.  These notices will always have subject headers of the form
'ARCHIVE: xxx', where xxx is a brief description of the new addition.

WARNING: Items stored in the archive is not guaranteed in any way to have
been tested for functionality or absence of virii.  Retrieve and use at your
own risk.

Mark Nagel <[e-mail]>










Path: ucivax!gateway
From: [e-mail] (Jamie McCarthy)
Subject: Debugger low-memory crashes
Message-ID: <[e-mail]>
X-Mailer: ELM [version 2.3 PL11]
Newsgroups: fa.think-c
Lines: 23
Date: 11 Jun 91 02:01:45 GMT

I just joined this list a few days ago; I scanned a few archives and
didn't find this, so I hope it isn't an FAQ...

While using the debugger set at the standard 200K a few days ago, I got
a "Debugger is low on memory--quit ASAP" message.  I quit.  When I tried
to "Run" from THINK C (debugger still on), it did nothing except dim the
menus as if the debugger and application were active--but I stayed in
the THINK C application.  "Resume" brought me back to editing/compiling.
Command-R from there on just toggled me in and out of editing and
"running" modes.

I went to check out the Debugger, and it was trashed somehow--the Finder
couldn't find the vers or SIZE resources for Get Info.  I duplicated it
and opened it up with ResEdit.  ResEdit reported it damaged, I extracted
what I could into a new file and quit.  Then--surprise--the old copy
suddenly worked.  I bumped memory up to 500K and it's been fine since.

Is this more serious than a low memory problem?  I don't mind keeping it
at more than 200K, if someone will reassure me that that crash-proofs it.
--
 Jamie McCarthy                        [e-mail]
 "To think I would never have painted if my legs had been just a little
 longer!" - Henri de Toulouse-Lautrec










Path: ucivax!gateway
From: [e-mail] (Nick Rothwell)
Subject: Re: ThinkC 4.0.5
Message-ID: <[e-mail]>
Newsgroups: fa.think-c
Lines: 25
Date: 13 Jun 91 12:10:32 GMT

>Since the update is technically a minor update, we did not mail users
>about it.  It was hoped that users would run Apple's Compatability
>Checker, find out that THINK C 4.0 was incompatible with System 7, and
>contact us directly.

Hmm. Grumble... I think I'd consider an upgrade from
totally-nonfunctional-under-7.0 to working-under-7.0 to be more than minor.
But then, if it was more than minor, it would cost money, right?

Talking of calling Symantec directly, I'm still in the dark about SUM-II.
The Compatibility Checker says to get hold of v2.0.1, but Symantec UK say
that there's no SUM-II for 7.0. Period. Now, an FTP upgrade of this would
be nice. I think, in general, it would have been nice to get a postcard or
something from Symantec saying "if you're getting 7.0, give us a call about
upgrades to X and Y." At least then, it would be clear that an upgrade was
needed and available. With SUM-II, I just hear conflicting stories.

On a more general note, bear in mind also that a lot of software firms
don't have phone support outside the US. Shouldn't they at least make an
attempt to notify their overseas customers of the situation?

Boy, I'm lucky I have USEnet...

        Nick.











Path: ucivax!gateway
From: [e-mail] (Paul Raulerson)
Subject: Re: ThinkC 4.0.5 [[ System 7 Upgrades ]]
Message-ID: <9106131421.AA02115@>
Newsgroups: fa.think-c
Lines: 13
Date: 13 Jun 91 14:25:07 GMT

So can't you guys from Sym. at least give us a hint of what will be in
the New Think-C (and Think-Pascal) releases?  :)

No doubt the compiler will run with 32bit addressing turned on, so I can get
at the rest of my real memory (the part residing above the 8meg limit) and
4.05 already generates 32bit clean applications.

Any hints you can drop us about new goodies?  I've heard that the release will
be more than just an upgrade to System-7 compatibility, but that's the limit. ;)

-Paul












Path: ucivax!gateway
From: [e-mail] (Ephraim Vishniac)
Subject: Re: ThinkC 4.0.5 [[ System 7 Upgrades ]]
Message-ID: <[e-mail]>
In-Reply-To: Your message of "13 Jun 91 14:25:07 GMT."
             <9106131421.AA02115@>
Newsgroups: fa.think-c
Lines: 16
Date: 13 Jun 91 15:55:46 GMT


   So can't you guys from Sym. at least give us a hint of what will be in
   the New Think-C (and Think-Pascal) releases?  :)

I'm not with Symantec, but someone who is (Rich Siegel) has already
said to me that the next version of Think C will be fully
ANSI-compliant. One nasty non-compliance in the current version is
that argument prototype information in the declaration of pointers to
procedures is silently ignored, even if "require prototypes" is turned
on. This can lead to really weird bugs since arguments default to
16-bit ints.

Ephraim Vishniac    [e-mail]   [e-mail]
 Thinking Machines Corporation / 245 First Street / Cambridge, MA 02142
        One of the flaws in the anarchic bopper society was
        the ease with which such crazed rumors could spread.










Path: ucivax!gateway
From: [e-mail] (egw)
Subject: floating point glue in 4.0.
Message-ID: <[e-mail]>
Newsgroups: fa.think-c
Lines: 15
Date: 13 Jun 91 19:18:56 GMT

  Subject:       floating point glue in 4.0.5
     Sent:       1:08 PM        6/13/91
I'm using Think C 4.0.5 and the libraries from the System 7 Golden Master CD
and I'm having problems using the 881 math functions (eg. sin(), cos(), etc).
There seems to be some glue routines missing (_elems, _fp1) which causes a link
failure.  Does anyone have this glue or has anyone got the direct 881 math
functions working.  I'm not interested in the SANE calls as they are far too
slow.

Thanks

Eric Wasserman
[e-mail]












Path: ucivax!gateway
From: [e-mail] (Mark Alldritt)
Subject: Re: CDirector question
Message-ID: <9106131216*[e-mail]>
Newsgroups: fa.think-c
Lines: 37
Date: 13 Jun 91 19:32:42 GMT

Thank you to Larry Watanabe and Martin Minow for responding to me questions
and confirming my observation that the supervisor of a CDirector must be the
application.

The solutions given by both Larry and Martin for my problem are more or less
what I have been considering.  My plan is to implement two new subclasses,
one based on CDocument and the other based on CDirector.  These new subclasses
would take care of the linkage between the supervising document and the
directors under its control.  I would then base my Documents and Directors on
these new classes.

struct CParentDocument : CDocument {

    CCluster    *itsChildren;

    void    IParentDocument(...);
    void    Dispose(void);    /* Send Close message to all children & dispose */

    void    AddChild(CChildDirector *aDirector);
    void    RemoveChild(CChildDirector *aDirector);
};

struct CChildDirector : CDirector {

    CParentDocument   *itsParent;

    void    IChildDirector(..., CParentDocument *itsParent);
                       /* Init the director and register it with the parent */
    void    Dispose(); /* Make the parent forget about this child & dispose */

    void    UpdateMenus(void);  /* Call the parent's UpdateMenus */
    void    DoCommand(long theCommand);  /* Call the parents DoCommand */
};

Thanks for your responses.

-Mark










Path: ucivax!gateway
From: [e-mail]
Subject: 4Plus and System 7.0 (also Alpha)
Message-ID: <9106161304.AA19794@husc10>
Newsgroups: fa.think-c
Lines: 10
Date: 16 Jun 91 13:06:28 GMT

Hi,

I just downloaded 4Plus after hearing (reading) many great things
about it but I cannot seem to get it to work.  I'm using an se/30 with
System 7.0 and THINK C 4.0.5.  Does anybody know how to get this to
work (if it can be made to work)?  On a related note has anyone gotten
the THINK C related ACMD's in Alpha 3.531 to work under System 7.0?
Much appreciation in advance...

--Erik ([e-mail], [e-mail])










Path: ucivax!gateway
From: infoserv!apple!well![e-mail] ("Brian M. Hamlin")
Subject: Re:  Test
Message-ID: <[e-mail]>
Newsgroups: fa.think-c
Lines: 6
Date: 16 Jun 91 18:05:40 GMT

Hello Kenton -

  I recv'd the 'test for bounce' mail.

  one of the masses
   -Brian










Path: ucivax!gateway
From: [e-mail] (Erik Evensen)
Subject: 4Plus and Sys 7
Message-ID: <9106162339.AA03138@husc9>
Newsgroups: fa.think-c
Lines: 18
Date: 17 Jun 91 00:39:14 GMT

Hi,

Thanks to the several people who replied to my query about using 4Plus
under System 7.  The key is to put the 4Plus init in the System Folder
not the Extensions folder.  Works like a charm now.  I'm just starting
to test it out but it looks good.  One thing I think would be useful
is if the key bindings matched those of emacs or if we could figure
out how to patch Alpha into THINK C as the editor.  Or at the very
least get auto wrap and flashing matching parenthesis...

The kind souls who responded:
Povl H. Pedersen ([e-mail])
John Miller      ([e-mail])
Mark Nagel       ([e-mail])
Juri Munkki      ([e-mail])

--Erik ([e-mail])











Path: ucivax!gateway
From: [e-mail]
Subject: think-list
Full-Name: Curtis P. Brown
Message-ID: <[e-mail]>
Posted-Date: Mon, 17 Jun 91 07:24:12 -0400
Newsgroups: fa.think-c
Lines: 6
Date: 17 Jun 91 11:24:35 GMT

Hi,
  Please remove me from the mailing list.

Thanks.

Curtis Brown: [e-mail]










Path: ucivax!gateway
From: [e-mail] (Lars Petrus)
Subject: Many languages
Message-ID: <[e-mail]>
Newsgroups: fa.think-c
Lines: 12
Date: 25 Jun 91 22:07:56 GMT

   What is the best way to adminster a Think C projekt with versions in
several different languages? Now I have one project for each language,
with a ResEdit file for each one. The problem is that whenever I want to
change something in the resources, I must do the same change in all the
different ResEdit files. This is boring and invites errors.

   Is there a better way?


"Madness is the first sign of dandruff" |   Email:   [e-mail]
   - Dr Winston O'Boogie                |   Reality: Lars Petrus, Solna, Sweden











Path: ucivax!gateway
From: [e-mail] (Kirk Swenson)
Subject: Re:  Many languages
Message-ID: <[e-mail]>
Newsgroups: fa.think-c
Lines: 32
Date: 26 Jun 91 01:35:38 GMT

Lars Petrus writes:

>   What is the best way to adminster a Think C projekt with versions in
>several different languages? Now I have one project for each language,
>with a ResEdit file for each one. The problem is that whenever I want to
>change something in the resources, I must do the same change in all the
>different ResEdit files. This is boring and invites errors.

I've never worked on such a project, but it seems to me that it would
make the most sense to have just one project and one resource file that
contains all of the resources for each language.  The resource numbers
could be offset by a constant amount and then #defines used to specify
the resources.  So you might have the following:

#define ENGLISH        1000
#define SWEDISH        2000
...
#define LANGUAGE    ENGLISH

#define DLOGresourceID    (128 + LANGUAGE)
#define WINDresourceID    (512 + LANGUAGE)
etc.

Now you only have to change the #define LANGUAGE statement and recompile
and all references to resources in the project will automatically use
the appropriate resource.  When making a global change to a resource,
you will still have to make the change for each language's resource,
but at least they'll be in the same file.  I haven't thought through all
of the implications of this, but it seems like it would do the job.

Kirk Swenson
[e-mail]










Path: ucivax!gateway
From: [e-mail] (EWING DAVID JAMES)
Subject: Re: Many Languages
Message-ID: <[e-mail]>
Newsgroups: fa.think-c
Lines: 13
Date: 26 Jun 91 03:26:49 GMT


This is where rez beats ResEdit.  With Rez, you could have a separate file for
each language (containing only the language-dependant resources), and have one
file file to contain the non-language dependant resources.  Each language file
would then include the common file.  Unfortunately, this does not work well
with Think C (it does when using MPW).  You could use the stand-alone version
of Rez, SARez, to do this.  Not great, but better than Kirk Swenson's
suggestion of using #define's in your code, since that would limit you to the
languages that the code know's about.

Dave Ewing
[e-mail]  (128.138.238.33)
AppleLink: D2408      ([e-mail])










Path: ucivax!gateway
From: [e-mail] (Paul Forrester)
Subject: Is this a compiler bug?
Message-ID: <[e-mail]>
Newsgroups: fa.think-c
Lines: 35
Date: 26 Jun 91 04:02:44 GMT


I've spent the last couple of days trying to find why when I added some memory
optimizations my program started crashing.

My optimization was to add some MoveHHi calls before locking down handles when
functions that allocate memory are to be called. ie before NewWindow() etc...

My first thought when things started crashing was that I hadn't locked something
down someplace, and with all of the new forced memory movement it was making
the bug show up more frequently.  I was finally able to track down the problem
to the following stmt:

    (*Qh)->hQuestSTE = NewSTE( ... );

I found that just prior to the call to NewSTE, (*Qh)->hQuestSTE contained NULL
as expected.  However, if I stepped over the call to NewSTE the result was still
NULL.

A HA you say.  The problem was in NewSTE. Easy.

This was not to be the case.  I started the program again, and this time I
stepped through NewSTE.  Everything worked exactly as it should.  I looked
at the return value just prior to returning, and it was perfect.  I stepped
out of the function and allowed the above assignment statement to complete and
it still contained NULL.

Well, I was tired of fooling around, so I cranked up TMON and looked at the
code surrounding the call to NewSTE.  It turns out the compiler does some funny
stuff in an attempt at optimization.  The first thing the compiler does is
take the local variable Qh and put it in register A0.  Then it pushes all
of the arguments to NewSTE.  The last thing that happens before the JSR is a
MOVE.L (a0),<some frame variable>.  Or in english, it dereferences Qh and saves
the result in a temp variable.  NewSTE then goes off and moves memory all overr
the place, and when we return the first thing that happens is
MOVE.L <some fram variable>,a0










Path: ucivax!gateway
From: [e-mail] (Paul Forrester)
Subject: Compiler problem continued...
Message-ID: <[e-mail]>
Newsgroups: fa.think-c
Lines: 55
Date: 26 Jun 91 04:12:44 GMT

I've spent the last couple of days trying to find why when I added some memory
optimizations my program started crashing.

My optimization was to add some MoveHHi calls before locking down handles when
functions that allocate memory are to be called. ie before NewWindow() etc...

My first thought when things started crashing was that I hadn't locked something
down someplace, and with all of the new forced memory movement it was making
the bug show up more frequently.  I was finally able to track down the problem
to the following stmt:

        (*Qh)->hQuestSTE = NewSTE( ... );

I found that just prior to the call to NewSTE, (*Qh)->hQuestSTE contained NULL
as expected.  However, if I stepped over the call to NewSTE the result was still
NULL.

A HA you say.  The problem was in NewSTE. Easy.

This was not to be the case.  I started the program again, and this time I
stepped through NewSTE.  Everything worked exactly as it should.  I looked
at the return value just prior to returning, and it was perfect.  I stepped
out of the function and allowed the above assignment statement to complete and
it still contained NULL.

Well, I was tired of fooling around, so I cranked up TMON and looked at the
code surrounding the call to NewSTE.  It turns out the compiler does some funny
stuff in an attempt at optimization.  The first thing the compiler does is
take the local variable Qh and put it in register A0.  Then it pushes all
of the arguments to NewSTE.  The last thing that happens before the JSR is a
MOVE.L (a0),<some frame variable>.  Or in english, it dereferences Qh and saves
the result in a temp variable.  NewSTE then goes off and moves memory all over t
the place, and when we return the first thing that happens is
MOVE.L <some fram variable>,a0
 .
 .
 .
The compiler then finishes the second dereference and computes the offset and
saves the return value which was in D0.  The only problem is that during the
call to NewSTE memory moved all around and invalidated the copy which the
compiler had made.

I thought that C compiler were supposed to evaluate the right side of an
equation completly before even looking at the left side.  Is this happening
because I'm using the parenthisis around
*Qh.  If I used the syntax **Qh. rather than (*Qh)-> would the problem not
hav occured?

Is this a compiler bug?

Paul Forrester
Software Development Support
Apple Computer Inc.
Internet: [e-mail]
Applelink: Forrester










Path: ucivax!gateway
From: [e-mail] (Jamie McCarthy)
Subject: Re: Compiler problem
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>; from "Paul Forrester" at Jun 26, 91 4:12 am
X-Mailer: ELM [version 2.3 PL11]
Newsgroups: fa.think-c
Lines: 42
Date: 26 Jun 91 06:19:37 GMT

Paul Forrester writes:
> I've spent the last couple of days trying to find why when I added some memory
> optimizations my program started crashing.
>
> I thought that C compiler were supposed to evaluate the right side of an
> equation completly before even looking at the left side.

Nope.  Order of evaluation is specified for &&, ||, ?:, and the comma
operator; all others are free birds.  This includes =, the assignment
operator.  See K&R 2nd ed., section 2.12 and Appendix section 7.  Page
53 reads:

One unhappy situation is typified by the statement
a[i] = i++;
The question is whether the subscript is the old value of i or the new.
... When side effects (assignment to variables [or moving memory around
in a heap]) take place within an expression is left to the discretion of
the compiler, since the best order depends strongly on machine
architecture.

> Is this happening
> because I'm using the parenthisis around
> *Qh.  If I used the syntax **Qh. rather than (*Qh)-> would the problem not
> hav occured?

Makes no difference.  Parentheses won't fix it.

> Is this a compiler bug?

No, it's documented--so it's a feature!  :-)  See the user's manual,
page 126 ("Tips"), esp. the second example ("(**aTEH).hText" etc.).

The solution is to HLock that puppy down.  When I optimize with MoveHHi,
I usually load in the resource as early as possible, MoveHHi it, HLock
it, and never touch it again.  Don't know if that's applicable in your
case; it sounds like you may need a different solution.  In general,
this kind of optimization is only useful when the heap is very
fragmented, and severely fragg'd heaps only occur when you have a lot of
locked handles (or nonrelocatable blocks).  It's probably better to keep
the heap as unlocked as possible as often as possible.
--
 Jamie McCarthy                           [e-mail]










Path: ucivax!gateway
From: [e-mail] (Your friendly neighbourhood Lab GTA)
Subject: Kirk's suggesetion for Lars' problem with many languages
Message-ID: <[e-mail]>
Newsgroups: fa.think-c
Lines: 13
Date: 26 Jun 91 12:57:29 GMT

Kirk had suggested using a #define statement to do the offsetting.
That's fine, except that it wouldn't be specified in the resources anymore,
which means if someone gets it in, say, the English version, and wants it
for Swedish, he would have difficulty changing it, even though all the
resources are there. Perhaps a better way would be to have a resource called
"language" and comments indicating what value to change it to in order
^("LNGE"?)
to get the language you want... or even a dialog box in Setups...?

Or, is there a way to just query the system to see what language it is localized
for?

Ian










Path: ucivax!gateway
From: [e-mail] (Phil Shapiro)
Subject: Compiler problem
Message-ID: <[e-mail]>
In-Reply-To: Jamie McCarthy's message of 26 Jun 91 06:19:37 GMT <[e-mail]>
Newsgroups: fa.think-c
Lines: 26
Date: 26 Jun 91 13:24:40 GMT

Yes, it isn't a bug that THINK C likes to evaluate the left hand side
after the right hand side in an assignment statement, and it doesn't
have anything to do with optimization.  It has to do with writing a
fast, single-pass compiler.

Re: the solution of calling HLock'ing the handle down first, I'd
recommend using an intermediate variable instead.  If you're going to
be friendly to the memory manager, then you should let it move your
handles around when it needs to allocate memory.  So, if you had:

    (*teH)->hText = NewHandle(1000);

you'd rewrite it as:

    Handle tempText;
    tempText = NewHandle(1000);
    (*teH)->hText = tempText;

I think that this is a little better with respect to the memory
manager, and it only costs a couple bytes of stack space.

    -phil
----
   Phil Shapiro                           Technical Support Analyst
   Language Products Group                     Symantec Corporation
        Internet: [e-mail]










Path: ucivax!gateway
From: [e-mail]
Subject: Introductory Texts on Mac Programming and Think C
Message-ID: <[e-mail]>
Newsgroups: fa.think-c
Lines: 29
Date: 26 Jun 91 14:48:44 GMT

At the risk of beating a dead horse, I pose the following:

I am a (somewhat) recent owner of Think C. However, although I am familiar
with several languages (Pascal, BASIC, HyperCard), I am somewhat less
familiar with C and even less so with Macintosh programming techniques. I
have a copy of Apple's _Programmer's Introduction to the Macintosh_, and I
am getting a feel for what is involved, but clearly this is not a text that
teaches specifics. I am considering _The Macintosh Programming Primer_, the
two-volume set whose author(s) I don't remember, as an addition to my
collection. Is this set effective? Are there any other texts worthy of
merit?

Again, I am not a stranger to programming; just to *Macintosh* programming.
As for C itself, I have several texts at my disposal; it would not be
necessary to find a book that teaches C along with Mac programming in
general.

(As an aside, how recommended is _Inside Macintosh, Vol VI_ compared to
_Inside System 7_, which seems to be a programmer's reference to the new
system software?)

Thanks in advance. (I hope!)

    David Pieczkiewicz      =========       =    [e-mail]
    Macintosh Specialist           \     ======= [e-mail]
    Information Network Services    \     / =    [e-mail]
    Case Western Reserve University =======      [phone]  (216)
791-7384











Path: ucivax!gateway
From: [e-mail] ("Richard E Beecher (907")
Subject: System 7 Prototypes/Header Files
Message-ID: <[e-mail]>
Newsgroups: fa.think-c
Lines: 18
Date: 26 Jun 91 18:49:41 GMT


I'll try to keep this short as I'm sure someone has already asked the question.
I have Inside Mac VI and I want to use some of the new Process Manager routines
but I don't have the new system 7 prototypes and header files for Think C.
I guess I could type them myself, but that doesn't exactly tickle my fancy.  I
don't have access to the Golden Master CD that I have heard all about (I don't
have a CD-ROM player anyway!).

What does one do my sort of situation?  Is Symmantec planning to release new
header files?  Have they already done so?  Any help here would be appreciated.

Thanks in advance,

Richard Beecher
ARCO Alaska, Inc.  (my paying job)
Anchor Beech Software Development  (my not-so-paying other job)

Internet:  [e-mail]










Path: ucivax!gateway
From: [e-mail]
Subject: Resource localization
Message-ID: <[e-mail]>
Newsgroups: fa.think-c
Lines: 20
Date: 26 Jun 91 19:05:43 GMT

I saw standalone versions of MPW's Rez and Derez tools out
on the net somewhere. They're called SARez and SADerez.

The basic program is this::
    make your English resource file with ResEdit
    decompile it with SADerez
    change all the relevant stuff in the Rez source file
    recompile it with SARez

Q.E.D.

 - Alex

P.S.    If anyone finds SARez and SADerez (I had them but lost
    them), perhaps they should be uploaded to the think-c
    archives.

--
Alex Chaffee -=- [e-mail]











Path: ucivax!gateway
From: [e-mail] (Phil Shapiro)
Subject: System 7 Prototypes/Header Files
Message-ID: <[e-mail]>
In-Reply-To: "Richard E Beecher (907"'s message of 26 Jun 91 18:49:41 GMT <[e-mail]>
Newsgroups: fa.think-c
Lines: 16
Date: 26 Jun 91 21:59:03 GMT

The System 7 interface files for THINK C (and THINK Pascal) are not
being distributed publically at this point.  They aren't trivial to
use, and can cause confusion as they're not necessary if you don't
want to take advantage of the new System 7/IM VI toolbox routines.

If you do want the interfaces and libraries, then email me directly
with your address, or call us up at [phone].  The next major
release of THINK C will fully support development under System 7, and
it will contain headers and libraries similar to those that we're
currently distributing.

    -phil
----
   Phil Shapiro                           Technical Support Analyst
   Language Products Group                     Symantec Corporation
        Internet: [e-mail]










Path: ucivax!gateway
From: [e-mail]
Subject: System 7 Prototypes/Header Files
Message-ID: <9106262301.AA15254@husc10>
In-Reply-To: Phil Shapiro's message of 26 Jun 91 21:59:03 GMT <[e-mail]>
Newsgroups: fa.think-c
Lines: 7
Date: 26 Jun 91 23:27:57 GMT

Phil,

I'd like to get a copy of the Sys  7 / IM VI interface files.  I need
this because I'm using the new features in QuickDraw such as GWorlds.
Thanks...

--Erik ([e-mail])










Path: ucivax!gateway
From: [e-mail] (Kirk Swenson)
Subject: Re:  System 7 Prototypes/Header Files
Message-ID: <[e-mail]>
Newsgroups: fa.think-c
Lines: 13
Date: 27 Jun 91 17:52:29 GMT

Phil Shapiro writes:

>The System 7 interface files for THINK C (and THINK Pascal) are not
>being distributed publically at this point.  They aren't trivial to
>use, and can cause confusion as they're not necessary if you don't
>want to take advantage of the new System 7/IM VI toolbox routines.

Weren't the System 7 interface files distributed with the THINK C
4.0.5 updater that was sent out on this conference?  I can't imagine
where else I could have gotten them.

Kirk Swenson
[e-mail]










Path: ucivax!gateway
From: [e-mail] (Curt Vandetta)
Subject: Books on Think-C and Sys. 7
Message-ID: <[e-mail]>
Mailer: Elm [revision: 64.9]
Newsgroups: fa.think-c
Lines: 25
Date: 27 Jun 91 22:16:14 GMT



   Hello folks,

   I've been given a lead on a couple of books for C-programing on the
   Macintosh.  The books are "Macintosh C Programming Primer Volume
   I and II" by Dave Mark and Cartwright Reed.

   Are these books any good?  And how much of them, if any, will be
   out dated by System 7?

   Thanks in advance,
   Curt

--
--------------------------------------------------------------------------

  Curt Vandetta                         College of Oceanography
  [e-mail]                     Oregon State University

--------------------------------------------------------------------------
  "It's been said that man only uses 10% of his ability, Einstein used
   11%.  But who determines which 10% we use?  Which 10% are you using?"
                                        -Warren Miller
--------------------------------------------------------------------------










Path: ucivax!gateway
From: [e-mail] (Michael McGuffey)
Subject: ** Need sample code for modeless dialogs w/textedit
Message-ID: <[e-mail]>
X-VMS-Cc: MCGUFFEY
Newsgroups: fa.think-c
X-VMS-To: IN%"[e-mail]"
Lines: 26
Date: 28 Jun 91 01:48:49 GMT
X-Envelope-to: [e-mail]


I'm working on my first Mac application using Think C 4.00. and am having
trouble getting my feet off the ground.   I want to produce a modeless
dialog with several TextEdit data entry items (i.e. numbers, report titles,
dates, etc.) and a few checkboxes.

I've looked around at the sample code and any apps-with-source I can find
but can't really find anything that has more than one TextEdit item.
(I usually just look at the dialog resources to check).

I'm particularly interested in some object-oriented starting point, but I
can't even find "normal" c code.   The Think C manual suggests starting
with TinyEdit for any textedit based app, but it looks like it's more for
"freeform" text entry.

Can anyone point me to some sample code skeleton (object-oriented preferably)
which will fit the bill?

Thanks,
-- michael
-----------------------------------------------------------------------------
Michael McGuffey, Director        BITNET:   mcguffey@marshall
Office of Institutional Research  Internet: [e-mail]
Marshall University               Phone:    [phone]
Huntington, WV 25755              FAX:      [phone]
-----------------------------------------------------------------------------










Path: ucivax!gateway
From: [e-mail] (Jamie McCarthy)
Subject: DeviceLoop call
Message-ID: <[e-mail]>
X-Mailer: ELM [version 2.3 PL11]
Newsgroups: fa.think-c
Lines: 6
Date: 29 Jun 91 20:09:23 GMT

I will kill or die to be able to use the DeviceLoop() routine,
documented in IM6 and declared in QuickDraw.h of Sunday, January 6, 1991
at 9:43 PM.  But I don't know if it's available under system 6 or not,
and my app needs to run under 6.  Can anyone help me?
--
 Jamie McCarthy                           [e-mail]










Path: ucivax!orion.oac.uci.edu!nntpsrv
From: [e-mail] (Bill Dugan)
Subject: CD-ROM .h file?
Nntp-Posting-Host: teri.bio.uci.edu
Message-ID: <[e-mail]>
Newsgroups: fa.think-c
Organization: University of California, Irvine
Lines: 6
Date: 29 Jun 91 23:20:50 GMT
Distribution: na

Is there any particular .h file I'll need to make calls to Apple's CD-ROM
driver?  I have in mind the "CD-ROM and the Macintosh, A Gentle, Technical
Introduction" document that has been around for a couple years, that  has
a host of calls listed in the back.

bill